As suggested in #1174 (comment)

I've added a few additional commits. This includes a Gemfile with the correct Rubocop version (the Gemfile.lock is ignored in git, so I left that one out) and updated Github Actions to use the gemfile. This means it's easier to run Rubocop on your home setup without having to worry about installing the correct version of Rubocop.

Mmh, one trouble with the Gemfile is if someone looks at this project they might think they should run bundle exec mspec or so to run specs, because there is a Gemfile at the root.
But on purpose ruby/spec avoids Bundler because subprocesses are a lot slower under Bundler and to keep things simple.

What I do locally is basically the same the CI does:
https://github.com/ruby/spec/blob/8aae62fbdc0e646ae775576d847beb60063ca253/.github/workflows/ci.yml#L75C12-L76
Except for the second command I use:

$ rubocop _1.28.2_ --parallel

(we could of course use that in CI too to be more explicit)

So I think either using that or adding a small script (e.g. bin/rubocop) which just runs rubocop _1.28.2_ *args is better than the Gemfile (it could also auto install the gem maybe).

Also since RuboCop 1.0 I think using a newer version of RuboCop has almost no observable behavior difference, so that should work fine too.

@herwinw Could you address #1180 (comment) ?
I think having a Gemfile at the root is not good because of those reasons so I would like to find another solution.

@herwinw Could you address #1180 (comment) ? I think having a Gemfile at the root is not good because of those reasons so I would like to find another solution.

My apologies, I completely overlooked that one. I will have a look at it tomorrow or the day after tomorrow.